Mobile communication device application processing system

ABSTRACT

A system and method of pre-linking classes for use by one or more applications. The system and method may also be used where the runtime processing is split between a host system and a target system. At the host system at least several classes are loaded and linked. At least one host-linked module is generated from the linked classes. The host-linked module is made available for use by the one or more applications operating on the target system.

RELATED APPLICATION

This application claims priority to U.S. provisional application Ser.No. 60/294,331 entitled “Method Of Splitting A Processing MachineRuntime Between A Host System And A Target System” filed May 30, 2001.By this reference, the full disclosure, including the drawings, of U.S.provisional application Ser. No. 60/294,331 is incorporated herein.

BACKGROUND

This invention relates to the field of processing machine runtimeenvironments. In particular, this invention relates to a method ofsplitting a processing machine runtime between a host system and atarget system for conserving resources at the target system.

Currently, the state of the art virtual machine is the Java™ virtualmachine (JVM) from Sun Microsystems, Inc. (Sun). At the centre of SunMicrosystems Java™ technology is their Java™ virtual machine code, orbyte code, as currently specified by the class file format in chapter 4of the second edition of The Java™ Virtual Machine Specification by TimLindholm and Frank Yellin, Addison-Wesley Pub Co; ISBN: 0201432943.

Class file byte code co-operates with Sun's Java™ Runtime Environment(JRE) on the Solaris™, Win32, Linux™, Mac, and possibly other platforms.Typically, source code written in the Java™ programming language, iscompiled into virtual machine byte code respecting the class file formatby using a Java™ compiler, such as “javac”, and then executed using theJRE or a compatible runtime environment and processing machine.

In reference to FIG. 1, a layered JRE architecture block diagramillustrates several aspects of the Sun technique. Various mechanisms(100A and 100B) provide program software (110A and 110B) byte code classfiles. For instance, a compiler 100A compiles software 110A into bytecode class files. Alternatively, a web browser may use a software“plugin” 110B to download software 100B byte code class files.

Byte code in a class file usually references several other classes, eachof which has a class file. For that reason, standard package 120 classfiles are provided as a shared software resource to be re-used byinstances of software (110A and 110B). The JVM 140 obtains class filesand executes software (110A and 110B) and standard package class files120.

Also shown are the various systems 130 on top of which the JRE 142operates. The standard packages in a runtime define a particular runtimeplatform specified in an application programmer's interface (API).

The Java™ 2 Standard Edition (J2SE) is a Sun reference platform API.They also provide a reference implementation comprising a JRE configuredwith a set of standard packages running on the JVM. Applicationdevelopers can write applications in the Java™ programming languagereferring to the J2SE standard package classes and may expect to havetheir applications run on J2SE compliant runtime systems. Otherplatforms exist which are usually defined by comparison to the J2SE. Forinstance, a superset of J2SE, the Java™ 2 Enterprise Edition (J2EE) addsfurther features. Of particular interest is a subset of J2SE, the Java™2 Micro Edition (J2ME).

Although the J2SE platform may be well suited to operate on systems suchas those illustrated by the Solaris™, Win32, Mac, Linux™, and otherblocks 130 of FIG. 1, J2SE may not be well suited for operating on manydevices. For instance, the class files of the standard J2SE packages maypresently consume well over 16 Megabytes of disk space, which may exceedthe storage capacity of many devices.

To address this problem, Sun introduced the Java™ 2 Micro Edition (J2ME)platform, additional virtual machines, and associated deviceconfigurations.

The Connected Limited Device Configuration (CLDC) and K Virtual Machine(KVM) address small consumer devices that you hold in your hand, with128K to 512K of memory, and when used with the Mobile Information DeviceProfile (MIDP) may provide an application environment for devices suchas cell phones and two-way pagers.

The Connected Device Configuration (CDC) and C Virtual Machine (CVM)address emerging, next-generation consumer devices with 2 MB or more ofmemory, and when used with the Foundation Profile (FP) may provide anapplication environment for next-generation consumer devices.

An advantage of J2ME is that when it is used with the aforementionedCLDC or CDC configurations, fewer standard class packages are stored onmany devices as compared to J2SE. Therefore J2ME may take up less spaceon a device at the expense of not supporting all of the features ofJ2SE.

Although Java™ runtime technology may be available for different systemsand devices, and although the J2ME platform addresses the limitedstorage space problem of devices by removing functionality, J2ME may notbe considered an adequate solution since it may not address theefficiency of a device runtime implementation. Thus, there is a need fora runtime that is optimized for a target device (as well as otherneeds).

In order to better understand the present invention, the followinginformation regarding Java runtime technology is provided. According toLindholm et al., in section §2.17.1 of the Sun JVM spec: “The Javavirtual machine starts execution by invoking the method main of somespecified class and passing it a single argument, which is an array ofstrings. This causes the specified class to be loaded (§2.17.2), linked(§2.17.3) to other types that it uses, and initialized (§2.17.4)”.Therefore by specifying the name of a “main” class when starting the JVM140 of FIG. 1, a class file will be loaded and execution of byte codeinstructions will begin at the static main entry point of that classfile. Furthermore, referenced types, such as classes, used by the “main”class will be linked and initialized. Depending on the use of otherclasses by the “main” class file, significant runtime resources will beconsumed in order to load and link used class files.

Java™ runtime technology requires that the runtime system load and linkall required class files each time a “main” class is specified forexecution, which may cause the precipitous consumption of resources on atarget system such as a device.

A typical Java™ application has at least one “main” class filecontaining a static main entry point, as well as possibly having severalsupporting class files.

The following example Java™ program listing is considered next:

public class Hello {   public static void main(String[] a) {    System.out.println(“Hello!”);     Bye.bye(a);   } } public class Bye{   public static void bye(String[] a) {     System.out.println(“Bye!”);  } }

The above listing provides source code for two classes, Hello and Bye,each of which can be compiled into class file format in a way which isknown to a person skilled in the art, such as by placing the source foreach class in a Hello.java file and a Bye.java file and using thecommand “javac Hello.java Bye.java” to obtain a Hello.class file andBye.class file.

The Hello class provides a static main entry point and is thereforesuitable to be specified as a “main” class when starting the JVM 140.

In reference to FIG. 2, the linking technique of the runtime of FIG. 1is considered in reference to the above example “Hello” program. Aplurality of class files 200 is available to the virtual machine 140 (ofFIG. 1). Each class file has symbolic information that is used by thevirtual machine 140 to resolve references to other used class files.

Typically, the Hello.class file 210A is loaded at 220A first as it isspecified when starting the JVM 140. The JVM 140 then proceeds toexecute byte code instructions at the main entry point of the loadedclass 220A. Since the Hello class 220A uses several standard packageclasses, the class files for the used classes will be loaded and linkedto the Hello class 220A. The Object.class file 210B will be loaded at220B and linked 230B to the 210A Hello class. Similarly, theString.class file 210C, System.class file 210D, and other class files210 used by the Hello class are loaded at 220C, 220D, 220 and linked at230C, 230D, and 230. The Hello class also uses the Bye class (asupporting class which is not a standard package class) so the Bye.classfile 210E will be loaded at 220E and linked at 230E.

Although not expressly shown in the drawings, each time a class file 210is loaded at 220 and linked at 230, any class files the loaded class 220uses might also be loaded and linked. For instance, in the case of theloaded supporting Bye class 220E, it uses many of the same classes asthe Hello class 210A. Depending on when the Bye class 220E is loaded andlinked 230E, the Bye class 220E may not have to load the class files 210that are common with classes also used and loaded by the Hello class.However, all classes used by Bye 220A will ultimately have to be linkedto Bye as well for Hello to be able to use the supporting Bye class. Thesituation is similar with standard package classes.

Traditional class file 210 loading (at 220) and linking (at 230) consumesignificant runtime resources and may slow down the execution of a“main” program 220A when loading and linking of class files is triggeredby the specification of a command to execute a program, as will bediscussed further next in reference to FIGS. 3A and 3B.

With reference to FIGS. 3A and 3B, a flowchart further illustrating theruntime linking technique of FIG. 2, particularly illustrating optionallate resolution, is discussed. The “main” class is loaded at 310 fromclass storage 200, such as a hard drive or a network. The class isverified and prepared at 315. If late resolution is not used asdetermined at 320, then all used classes are linked and loaded at 325.Regardless of whether late resolution is used at 320 or not, the “main”class is initialized at 330.

Instructions from the main entry point are fetched at 335. If thefetched instruction does not involve an unresolved reference asdetermined at 340, the fetched instruction is. executed at 345. Howeverif the fetched instruction involves an unresolved identifier referenceas determined at 340, such as a class reference to a class that has notyet been loaded, then if late resolution is not used as determined at350, an exception is thrown in the runtime. If late resolution is usedas determined at 350, and if the referenced class cannot be loaded at355, an exception is thrown in the runtime. However, if late resolutionis used as determined at 350, and the referenced class can be loaded,the referenced class is loaded and the reference is resolved at 360prior to executing the instruction at 345. If there are moreinstructions to execute as determined at 365, then the next instructionis fetched at 335, or else the virtual machine ends.

If late resolution were used, then several class files would have beenloaded and linked at 360 during execution of the main program byte code.Alternatively, if late resolution were not used, several class fileswould have been loaded and linked at 325 prior to executing the mainprogram byte code, after specifying the “main” class file to the JVM140. In either case, a precipitous consumption of resources for loadingand linking may ensue between the time the main program was specifiedfor execution by the JVM 140 in the runtime and the time when the mainprogram either terminated or threw an exception.

Therefore, even by eliminating late resolution, there is a potentialrisk for a precipitous consumption of resources for loading and linkingclass files in execution triggered linking and loading.

SUMMARY

The present invention overcomes the problems noted above as well asothers. In accordance with the teachings of the present invention, asystem and method are provided for pre-linking classes for use by one ormore applications. The system and method may also be used where theruntime processing is split between a host system and a target system.At the host system at least several classes are loaded and linked. Atleast one host-linked module is generated from the linked. classes. Thehost-linked module is made available for use by the one or moreapplications operating on the target system.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the invention may be more clearly understood, embodimentsthereof will now be described in detail by way of example only, withreference to the accompanying drawings, in which:

FIG. 1 is a block diagram illustrating a prior art runtime technique;

FIG. 2 is a block diagram illustrating a linking technique of theruntime of FIG. 1;

FIGS. 3A and 3B are flowcharts further illustrating the runtime linkingtechnique of FIG. 2, particularly illustrating optional late resolution;

FIGS. 4 and 5 are block diagrams illustrating an exemplary split runtimesystem;

FIGS. 6 and 7 are block diagrams illustrating different exemplary splitruntime systems;

FIG. 8 is a block diagram illustrating a linking technique for a splitruntime system;

FIG. 9 is a flowchart further illustrating the linking technique of FIG.8, introducing a host-linking step and a target-linking step;

FIG. 10 is a flowchart further illustrating the host-linking step ofFIG. 9; and

FIG. 11 is a flowchart further illustrating the target-linking step ofFIG. 9.

The same reference numerals are used in different figures to refer tosimilar elements.

DETAILED DESCRIPTION

FIG. 4 depicts an embodiment of a module-based runtime system. Insteadof unlinked class files, a processing machine 440 executes modules 450that include classes that have already been loaded and linked. Morespecifically, the modules 450 comprise the information found in closedset loaded and linked class files, thereby optimizing commands, symbolicinformation, and code size and speed for the target processing machine440. Modules 450 allow the runtime to re-use the intermediate loadingand linking work in multiple executions of main programs, instead ofrepeating this work at every execution. Modules 450 provide analternative to execution triggered loading and linking.

A compiler (or other mechanism) 405 receives a class file 407 whichinclude symbolic references 409 to other classes 411. The compiler 405processes class files 407 and 411 which are in byte code such that thesymbolic references 409 are resolved. The processed class files areprovided to the processing machine 440 as modules 450. The processingmachine 440 operates more efficiently on target devices 430 sincetypically the module size is substantially smaller than traditionalruntime class files, for example, there may be a reduction approximatelyeight-fold in comparison to Java class file size. Also, module code canbe verified once using sanity checks prior to multiple executions,thereby increasing subsequent execution speeds. Modules can beconfigured to minimize code communication, particularly useful incommunication bandwidth-limited devices. Modules 450 can be configuredto minimize code set up and execution time, particularly useful inruntime resource-limited devices. Modules 450 can be adapted to existingprocessing machine runtimes while maintaining compatibility withreference APIs, as FIG. 5 illustrates.

FIG. 5 illustrates an embodiment wherein various mechanisms 405A and405B provide software 410. A compiler 405A compiles software 410.Alternatively, other mechanisms 405B can be used to download orotherwise obtain software 410. Standard class packages 420 are providedas a shared software resource to be re-used by instances of software410. The processing machine 440 obtains classes and executes software410 using standard class packages 420.

Also shown are the various target devices 430 on top of which theprocessing machine 440 operates, such as a mobile device 430A, apersonal data assistant (PDA) 430B, an appliance 430C, a thin client430D, or other device 430E.

In FIG. 5, modules 450 have been introduced between the mechanism thatprovides software 410 and the processing machine 440 that executesmachine code. The processing machine 440 however still uses the classesin the provided software 410 as well as the standard class packages 420,except that this is now done through the use of modules 450 rather thandirectly using class files. Class files can still be used as thecompiler can take both class files and source files on its input andproduce modules on its output.

Because of the presence of modules 450, the processing machine 440 neednot be a virtual machine nor even know about the class file format,thereby optimizing performance at the target system by eliminating theneed to load, link, and resolve class files. Further optimizations arepossible if the provided runtime is split between a host system and atarget device 430, as described in reference to FIG. 6.

FIG. 6 illustrates a split embodiment of a module-based runtime system.The class runtime processing is split between a host system 530 and atarget system 430. The use of modules allow the runtime to beefficiently split between a host system and target device to optimizeruntime efficiency at the target device.

In the host system split runtime, class files (407 and 411) arehost-linked at 510 into host-linked modules 520. The work of closedclass file set analysis is offloaded to the host system 530. In thetarget system split runtime, host-linked modules 520 are communicated at540 from the host system 530, to be target-linked at 550 intotarget-linked modules 560. If any additional class resolution is neededon the target system 430, then the additionally needed target moduleidentifiers 562 are target-linked at 550 with the host-linked modules520 to form the target-linked modules 560. The processing machine 440executes the target-linked modules 560.

FIG. 7 is a block diagram illustrating another split runtime system. Forthe host system 530, class files 410 are host-linked at 510 intohost-linked modules 520. For this system, the details of host linkingwill be discussed further in reference to FIGS. 8, 9 and 10 below. Forthe target system 430, host-linked modules 520 are communicated at 540from the host system 530, to be target-linked 550 into target-linkedmodules 560. The communication 540 between host and target may occurover any medium so that the module(s) may be provided to the target,such as through a mobile communications network if the target is amobile communications device, or through a data signal embodied in acarrier signal. The details of target linking will be discussed furtherin reference to FIGS. 8, 9 and 11 below.

In reference to FIG. 8, a block diagram illustrating the loading ofclass files, and the split linking into modules, and execution of thesplit module runtime of FIGS. 6 and 7 is described presently. The workof closed class file set analysis is offloaded into a host system 400A.There, class files 600 are loaded at 610 and linked into host-linkedmodules 520A and 520F. Illustrated are an application module for theexample “Hello” module 520A comprising the optimized information foundin the Hello.class file 610A and Bye.class file 610E wherein the Helloclass is pre-linked to the Bye class. Module 520A also has a symbolicreference 615 to a Library module 520F which comprises all of thestandard package classes that the Hello and Bye classes use, such as theclasses provided by the Object class file 610B, String class file 610C,System class file 610D, and other class files 610. The Library module520F could export all public symbols so that many different “main”classes such as Hello can re-use all of the standard class packagefiles. Altematively, the Library module could comprise only those classfiles used by the Hello and Bye classes, or even all used classes couldbe included directly in module 520A. The latter case would eliminate theneed for any symbol resolution on the target system.

When at least one host-linked module (520A and/or 520F) is available, itis possible to communicate at 540 the candidate module 620A and 620F tothe split runtime on the target system 400B. Once the candidate modules(620A and 602F) are received on the target system, it is target-linkedinto a target-linked module 560A and 560F and any module symbolicreferences 615 are resolved as shown at 630. A main module class can bespecified for execution, such as the Hello class 640. However,advantageously, each time the main program of the Hello class executes,there is no need to resolve reference 650 as the target-linking 630provides it.

With reference to FIG. 9, a flowchart further illustrating the linkingtechnique of FIG. 8, depicting a host-linking step and a target-linkingstep, is described. In the split runtime system on the host, classes 600are loaded and host-linked at 800 into host linked modules 520. Then, atleast one host-linked module 520 is sent to the split runtime system onthe target.

In the split runtime system on the target, at least one candidatehost-linked module 620 is received at 720 from the host. The candidatehost-linked module 620 is target-linked at 900 into a target-linkedmodule 560. At least one target-linked module 560 is executed at 730. Ifa new module is desired as determined at 740, the host-linking process800, communications processes (710 and 720) and target linking process900 cycles may ensue. However, if no new modules are desired, thenrepeated execution at 730 of target-linked modules can ensue without theoverhead of loading and linking.

In reference to FIG. 10, a flowchart further illustrating thehost-linking step of FIG. 9 is described. In the split runtime system onthe host, host linked modules 520 exported symbols provide at 810foreign module identifiers 815. Also, classes 600 provide at 820candidate host classes 825. Class references in the candidate hostclasses 825 are replaced at 830 with module references using foreignmodule identifiers 815, thereby providing closed set candidate moduleclasses 835. Then, candidate module exported identifiers 845 areprovided at 840. The candidate module classes 835 and exportedidentifiers 845 are then verified at 850. If verified as determined at860, then the candidate host-linked module is provided at 870 as ahost-linked module 520. If not verified as determined at 860, anexception is thrown.

In reference to FIG. 11, a flowchart further illustrating thetarget-linking step of FIG. 9 is described. In the split runtime systemon the device, the received candidate module 620 provides at 910candidate module references 915. Also, target-linked modules 560provides at 920 target module identifiers 925. Next, resolution ofmodule references in the candidate module provides at 930 a resolvedmodule 935. The resolved module 935 is verified at 940, and if theresolved module 935 is verified successfully as determined at 950, thenthe resolved module 935 is stored at 960 with other target-linkedmodules 560. However, if the resolved module 935 is not verifiedsuccessfully as determined by 950, an exception is thrown.

Having described in detail the preferred embodiments of the presentinvention, including preferred modes of operation, it is to beunderstood that this invention and operation could be constructed andcarried out with different elements and steps. The embodiments arepresented only by way of example and are not meant to limit the scope ofthe system and method of the present invention, which is defined by theclaims.

To illustrate the wide scope of the system and method, the following isprovided. Virtual machine code is usually interpreted by software.However, a virtual machine code processor can be implemented inhardware. Adaptation of the system and method to a hardware processingmachine runtime is within the scope of the invention. As additionalexamples of the wide scope of the system and method, the system andmethod may allow for the optimization of commands, symbolic information,and code through the use of the system's and method's modules. Thesystem and method may allow for a module size that is substantiallysmaller than traditional runtime class file, for instance by reducing insome cases by eight-fold the module size in comparison to Java classfile size without losing functionality. The system and method mayprovide that module code can be verified using sanity checks once priorto multiple executions.

The system and method may also allow a module to combine only newclasses to minimize module storage size and allow for efficient moduledelivery to communication bandwidth-limited devices. As another exampleof the wide scope of the system and method, the system and method cancombine all required classes to minimize code set up and execution timein resource-limited devices. The system and method may be adapted toexisting processing machine runtimes while maintaining compatibilitywith reference APIs. The system and method may provide that modules canbe dynamically linked together while minimizing the number of symbolicreferences. Still further, the system and method may provide that codein modules can be executed directly from storage on a device, unlikeclass files that have to be loaded from storage prior to execution.

1. A mobile communications device runtime system for executing an application, comprising: a processor-readable memory for storing a pre-linked module that includes a plurality of class files that have been loaded and linked, said pre-linked module having information about said loaded and linked class files, said pre-linked module being generated without requiring a prior determination of whether data associated with said pre-linked module will change, said pre-linked module being provided to said processor-readable memory over a network connection and having multiple pre-linked classes; an application operative on a target mobile communication device, wherein the application uses the classes during the application's execution, said application having access to the pre-linked module in said processor-readable memory during execution of the application, whereby need for the application to repeat loading and linking of the class files is eliminated during the execution of the application due to the use of the pre-linked module, wherein the pre-linked module comprises a plurality of modules, said modules being dynamically linked while substantially minimizing a number of symbolic references, wherein the application is operative on the target device, wherein the pre-linked module is directly executable from said processor-readable memory on the device, wherein the pre-linked module provides re-use of loading and linking steps in executions of multiple applications operating on the device, wherein the pre-linked module is configured based upon code set up at execution time, and wherein the application operates upon a bandwidth-limited device.
 2. The system of claim 1 wherein the application operates upon the target device; wherein the network connection comprises a mobile communication network for providing the pre-linked module for use by the application.
 3. The system of claim 2 wherein the target device includes target-linking means for target-linking the pre-linked module with other modules for use by the application.
 4. The system of claim 1 wherein the pre-linked module substantially optimizes commands, symbolic information, and code; wherein the symbolic information in the pre-linked module has been resolved.
 5. The system of claim 1 wherein the class files contain the classes and comprise symbolic information.
 6. The system of claim 1 wherein the pre-linked module is verified.
 7. The system of claim 1 wherein the pre-linked module comprises a plurality of modules that contain all class files needed by the application.
 8. The system of claim 1 wherein the pre-linked module is generated prior to execution of the application.
 9. The system of claim 1 wherein the application operates upon a mobile data device.
 10. The system of claim 1 wherein the application operates upon a personal data assistant.
 11. The system of claim 1 wherein the application operates upon a wireless mobile communication device.
 12. The system of claim 1 wherein the application operates upon a thin client application.
 13. The system of claim 1 wherein said plurality of class files comprise Java-based class files.
 14. A method of host-linking class files at a host computer system for use by an application that operates on a target system, comprising: loading at the host system at least several class files; linking at the host system the loaded class files; forming at least one host-linked module from the linked class files, said host-linked module generated without requiring a prior determination of whether data associated with said host-linked module will change; and storing at the host system said host-linked module in a processor-readable memory, wherein the host-linked module having multiple pre-linked classes files is made available over a network connection for use by the application operating on the target system, wherein the host-linked module comprises a plurality of modules, said modules being dynamically linked while substantially minimizing a number of symbolic references, wherein the host-linked module provides re-use of the loading and the linking steps in multiple executions of the application, wherein the host-linked module provides re-use of the loading and the linking steps in multiple executions of the application and of a second application, wherein the host-linked module is configured based upon code set up at execution time, and wherein the target system comprises a bandwidth-limited device.
 15. The method of claim 14 wherein a services application provides at least one of the class files to be used in said loading step at the host system.
 16. The method of claim 14 wherein a software library provides at least one of the class files to be used in said loading step at the host system.
 17. The method of claim 14 wherein a Java application provides at least one of the class files to be used in said loading step at the host system.
 18. The method of claim 14 wherein the linking of the loaded class files at the host system substantially optimizes commands, symbolic information, and code.
 19. The method of claim 14 wherein the class files comprise symbolic information.
 20. The method of claim 14 further comprising the step of: verifying at the host system the host-linked module using sanity checks.
 21. The method of claim 14 further comprising the step of: verifying at the host system the host-linked module using sanity checks once prior to multiple executions of the host-linked module on the target system.
 22. The method of claim 14 wherein the host-linked module comprises a plurality of modules that contain all class files needed by the application.
 23. The method of claim 14 wherein the host-linked module is directly executable from storage on the target system.
 24. The method of claim 14 wherein the host-linked module comprises information of closed set loaded and linked class files.
 25. The method of claim 14 wherein the host system resolves module references during generation of the host-linked module.
 26. The method of claim 25 wherein the host-linked module being provided to the target system eliminates need for the target system to resolve classes associated with the host-linked module.
 27. The method of claim 14 wherein the host-linked module is generated prior to execution of the application.
 28. The method of claim 14 wherein the host-linked module is configured based upon code communication to the target system.
 29. The method of claim 14 further comprising the step of: providing the host-linked module to the target system for use by the application.
 30. The method of claim 14 further comprising the step of: transmitting the host-linked module from the host system to the target system over the network connection which comprises a mobile communication network for use by the application.
 31. The method of claim 14 further comprising the step of: dividing processing machine runtime between the host system and the target system by forming at the host system the host-linked module and by target-linking at the target system the host-linked module into at least one target-linked module for use by the application.
 32. The method of claim 31 further comprising: executing said application on said target system; requesting a new pre-linked module from said host system at said target system by said application; creating said new pre-linked module by said host system in response to said request; transmitting said new pre-linked module to said target system over said network connection from said host system; and continuing execution of said application on said target system using said new pre-linked module.
 33. The method of claim 14 further comprising the step of: target-linking at the target system the host-linked module with other modules for use by the application.
 34. The method of claim 33 further comprising the step of: providing a table of exported identifiers for use in the linking of the loaded class files at the host system.
 35. The method of claim 14 wherein the target system comprises a processing machine for executing the application.
 36. The method of claim 14 wherein the target system comprises a virtual machine for executing the application.
 37. The method of claim 14 wherein the target system comprises a mobile data device.
 38. The method of claim 14 wherein the target system comprises a personal data assistant.
 39. The method of claim 14 wherein the target system comprises an appliance.
 40. The method of claim 14 wherein the target system comprises a thin client application.
 41. The method of claim 14 wherein the target system comprises a virtual machine code processor to process the host-linked module.
 42. The method of claim 14 wherein the target system comprises a hardware processing machine runtime to process the host-linked module.
 43. The method of claim 14 wherein the class files comprise Java-based class files.
 44. A method of handling a host-linked module at a target system, said host-linked module having been generated by a host system through loading at least several class files, said host system linking at the host system the loaded class files and forming at least one host-linked module from the linked class files, said method comprising: receiving the host-linked module, which has multiple pre-linked classes, at the target system from the host system over a network connection, said pre-linked module generated without requiring a prior determination of whether data associated with said pre-linked module will change; determining whether any additional class files are to be linked with the host-linked module, if additional class files are to be linked, then linking the host-linked module with the additional class files to form a target-linked module; storing said target-linked module in a processor-readable medium; accessing the target-linked module in order to enable the target-linked module to be used by an application operating on the target system; and dividing processing machine runtime between the host system and the target system by forming the host-linked module at the host system and by target-linking at the target system the host-linked module into at least one target-linked module for use by the application, wherein the host-linked module comprises a plurality of modules, said modules having been dynamically linked while substantially minimizing number of symbolic references, and wherein the host-linked module provides re-use of the loading and the linking steps in multiple executions of the application and of a second application.
 45. The method of claim 44 wherein the host-linked module being provided to the target system eliminates the target system from resolving classes associated with the host-linked module.
 46. The method of claim 44 wherein the host-linked module being provided to the target system eliminates need for the target system to resolve classes associated with the host-linked module.
 47. The method of claim 44 wherein the target system comprises a bandwidth-limited device.
 48. The method of claim 44 wherein the target system comprises a processing machine for executing the application.
 49. The method of claim 44 wherein the target system comprises a virtual machine for executing the application.
 50. The method of claim 44 wherein the target system comprises a mobile data device.
 51. The method of claim 44 wherein the target system comprises a personal data assistant.
 52. The method of claim 44 wherein the target system comprises an appliance.
 53. The method of claim 44 wherein the target system comprises a thin client application.
 54. The method of claim 44 wherein the target system comprises a virtual machine code processor to process the host-linked module.
 55. The method of claim 44 wherein the target system comprises a hardware processing machine runtime to process the host-linked module.
 56. The method of claim 44 wherein the class files comprise Java-based class files.
 57. The method of claim 44 wherein the host-linked module was verified at the host system using sanity checks once prior to multiple executions on the target system.
 58. The method of claim 44 wherein the host-linked module comprises a plurality of modules that contain all class files needed by the application.
 59. The method of claim 44 wherein the host-linked module is directly executable from storage on the target system.
 60. The method of claim 44 wherein the host-linked module provides re-use of the loading and the linking steps in multiple executions of the application.
 61. The method of claim 60 wherein the host system resolves module references during generation of the host-linked module.
 62. The method of claim 44 wherein the host-linked module is generated prior to execution of the application.
 63. The method of claim 44 wherein the host-linked module is configured based upon code communication to the target system.
 64. The method of claim 44 wherein the host-linked module is configured based upon code set up at execution time.
 65. The method of claim 44 further comprising the step of: receiving the host-linked module from the host system at the target system over the network connection which comprises a mobile communication network.
 66. A module-based runtime system for executing an application, comprising: a processor-readable memory storing a pre-linked module that includes class files that have been loaded and linked, said pre-linked module having information of closed set loaded and linked class files, said pre-linked module being generated without requiring a prior determination of whether data associated with said pre-linked module will change, said pre-linked module, which has multiple pre-linked classes, being provided to an application over a network connection; an application that uses the class files during the application's execution, said application having access to the pre-linked module in said processor-readable memory for use during execution of the application, whereby need for the application to repeat loading and linking of the class files is eliminated during the execution of the application due to the use of the pre-linked module, wherein the pre-linked module comprises a plurality of modules, said modules being dynamically linked while substantially minimizing a number of symbolic references, wherein the application is operative on a target device, wherein the pre-linked module is directly executable from said processor-readable memory on the device, wherein the pre-linked module provides re-use of loading and linking steps in executions of multiple applications operating on the device, wherein the pre-linked module is configured based upon code set up at execution time, and wherein the application operates upon a bandwidth-limited device.
 67. A mobile communications device runtime system for executing an application, comprising: a processor-readable memory for storing a pre-linked module that includes a plurality of class files that have been loaded and linked, said pre-linked module having information about said loaded and linked class files, said pre-linked module being generated without requiring a prior determination of whether data associated with said pre-linked module will change, said pre-linked module being provided to said processor-readable memory over a network connection and having multiple pre-linked classes; an application operative on a target mobile communication device, wherein the application uses the classes during the application's execution, said application having access to the pre-linked module in said processor-readable memory during execution of the application, whereby need for the application to repeat loading and linking of the class files is eliminated during the execution of the application due to the use of the pre-linked module, wherein the pre-linked module substantially optimizes commands, symbolic information, and code, wherein the symbolic information in the pre-linked module has been resolved, wherein the application is operative on the target device, wherein the pre-linked module is directly executable from said processor-readable memory on the device, wherein the pre-linked module provides re-use of loading and linking steps in executions of multiple applications operating on the device, wherein the pre-linked module is configured based upon code set up at execution time, and wherein the application operates upon a bandwidth-limited device.
 68. The system of claim 67 wherein the pre-linked module comprises a plurality of modules, said modules being dynamically linked while substantially minimizing a number of symbolic references.
 69. A method of host-linking class files at a host computer system for use by an application that operates on a target system, comprising: loading at the host system at least several class files; linking at the host system the loaded class files;- forming at least one host-linked module from the linked class files, said host-linked module generated without requiring a prior determination of whether data associated with said host-linked module will change; storing at the host system said host-linked module in a processor-readable memory; dividing processing machine runtime between the host system and the target system by forming at the host system the host-linked module and by target-linking at the target system the host-linked module into at least one target-linked module for use by the application; target-linking at the target system the host-linked module with other modules for use by the application; and providing a table of exported identifiers for use in the linking of the loaded class files at the host system, wherein the target system comprises a bandwidth-limited device, and wherein the host-linked module having multiple pre-linked classes files is made available over a network connection for use by the application operating on the target system.
 70. The method of claim 69 wherein the host-linked module provides re-use of the loading and the linking steps in multiple executions of the application.
 71. The method of claim 69 wherein the host-linked module comprises a plurality of modules, said modules being dynamically linked while substantially minimizing number of symbolic references.
 72. The method of claim 69 wherein the host-linked module provides re-use of the loading and the linking steps in multiple executions of the application and of a second application.
 73. The method of claim 69 wherein the host-linked module is configured based upon code set up at execution time. 